chore(FR-2866): disable gitBranchLockfile and retire weekly merge workflow#7359
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has required the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
There was a problem hiding this comment.
Pull request overview
This PR disables pnpm’s per-branch lockfile behavior by removing gitBranchLockfile: true, and retires the scheduled GitHub Actions workflow that existed only to reconcile branch lockfiles. It also updates the internal .claude command documentation so it no longer instructs contributors/agents to run obsolete lockfile-merge steps.
Changes:
- Remove
gitBranchLockfile: truefrompnpm-workspace.yamlso installs update the canonicalpnpm-lock.yamldirectly. - Delete
.github/workflows/weekly-merge-branch-lockfiles.yml(no longer needed without branch lockfiles). - Update
.claude/commands/bump-alpha-version.mdto remove the “merge branch lockfiles” step and renumber verification steps accordingly.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
pnpm-workspace.yaml |
Removes pnpm per-branch lockfile setting so the workspace uses a single canonical lockfile. |
.github/workflows/weekly-merge-branch-lockfiles.yml |
Deletes the scheduled reconciliation workflow that merged pnpm-lock.*.yaml into pnpm-lock.yaml. |
.claude/commands/bump-alpha-version.md |
Removes obsolete lockfile-merge instructions and updates the workflow steps/output summary. |
|
@copilot review This PR has a second commit since the last review ( |
Re-reviewed the latest state at |
0d6ef44 to
fe56916
Compare
Document the project convention for resolving pnpm-lock.yaml conflicts: always take main's version (via `git restore --source=main` or context- aware `git checkout --theirs`/`--ours`) and re-run `pnpm install` to let pnpm reconcile any new deps from the branch's package.json. This is the natural follow-up policy now that gitBranchLockfile is disabled and pnpm-lock.yaml is the single shared lockfile across all branches.
fe56916 to
17b1a57
Compare
yomybaby
left a comment
There was a problem hiding this comment.
충돌 해결 확인했습니다. pnpm-workspace.yaml에서 main의 enableGlobalVirtualStore: true는 유지하고, 이 PR의 의도대로 gitBranchLockfile: true만 제거되도록 머지했습니다. TS/lint/format 모두 PR 변경 범위 외이며 main과 동일 상태입니다.

Resolves #7357(FR-2866)
Summary
Disables pnpm's per-branch lockfile feature (
gitBranchLockfile: true), retires the weekly reconciliation workflow that existed solely to support it, and documents the convention for resolvingpnpm-lock.yamlconflicts now that all branches share a single canonical lockfile.Changes
pnpm-workspace.yaml: removegitBranchLockfile: true. pnpm will now write directly to the canonicalpnpm-lock.yamlon every branch..github/workflows/weekly-merge-branch-lockfiles.yml: delete. WithgitBranchLockfileoff there are nopnpm-lock.<branch>.yamlfiles to merge, so this scheduled workflow has no remaining purpose..claude/commands/bump-alpha-version.md: drop the obsolete "Merge pnpm Branch Lockfiles" step and matching references in the Commands Reference, Output Summary, and Example Workflow sections. Renumber the surrounding steps. Without this cleanup, future/bump-alpha-versionruns would try to use a flag that no longer applies to anything..claude/rules/pnpm-lockfile-conflicts.md(new): document the project convention for resolvingpnpm-lock.yamlconflicts — always take main's version (recommended:git restore --source=main pnpm-lock.yaml; in merge:git checkout --theirs; in rebase /gt sync/gt restack:git checkout --ours) then runpnpm installto let pnpm reconcile any new deps. The rule also calls out the well-known Git footgun that--ours/--theirssemantics swap between merge and rebase contexts.Why
Per the issue (#7357):
Lockfile state
pnpm-lock.yaml— the most recent weekly rollup landed in PR chore: weekly merge of branch lockfiles into main #7322, so there are no localpnpm-lock.<branch>.yamlfiles to merge in this PR.pnpm-lock.yamlis not modified by this PR. The dependency graph is unchanged.Migration for contributors with stale branch lockfiles
If you have an open feature branch carrying its own
pnpm-lock.<branch>.yaml, pnpm will not delete that orphan file automatically once this PR merges — new installs will simply write topnpm-lock.yaml, leaving the per-branch file sitting alongside it. After rebasing onto main:(
pnpm-lock.*.yamlis a shell glob that does not matchpnpm-lock.yaml, so the canonical lockfile is preserved.)Going forward:
pnpm-lock.yamlconflict resolutionNow that every branch writes to the same
pnpm-lock.yaml, lockfile merge conflicts will occasionally happen during rebase /gt sync. The new rule at.claude/rules/pnpm-lockfile-conflicts.mdcodifies the recipe:The rule covers the rebase / merge
--ours/--theirsswap, explains why hand-merging the lockfile is unsafe, and notes that taking main's lockfile without runningpnpm installwill break--frozen-lockfilein CI if your branch added new deps.Related
Checklist:
.claude/commands/bump-alpha-version.mdupdated;.claude/rules/pnpm-lockfile-conflicts.mdadded; migration note in this PR body)